ECSのオペレーションを劇的に簡略化するAWS Copilotが発表されました！

ECSの運用において作成しなければならない膨大なAWSリソースを劇的に簡単なコマンドでまるっと作成〜運用〜管理できるコマンドラインツールCopilotの紹介です。

#AWS Copilot

#Amazon ECS

#コンテナ

#AWS Fargate

#AWS

濱田孝治

2020.07.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「いざECSの運用はじめようとしても、作らないといけないものめっちゃあるよなぁ。正直しんどい…」

ECS環境の構築って考慮が必要な項目ってものすごく多いんですよね。ネットワーク関連、ロードバランサー、リポジトリ、データベース、ECSそのもの、さらにそれをデプロイするためのパイプラインやデプロイ設定。

そんな辛さを一気に解消するAWS Copilotが発表されました！

AWS Copilot のご紹介 | Amazon Web Services ブログ

英語のブログ記事と同じタイミングで日本語がでるとは、toriの人も相当気合が入ってますね！

Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！

−トリ (皆さまからの Copilot へのフィードバック、心よりお待ちしております)
引用：AWS Copilot のご紹介 | Amazon Web Services ブログ

というわけで、この記事ではGitHubリポジトリを眺めながら、AWS Copilotが実際何ができるのかを、コマンドと出来上がったリソースを振り返りながら見ていこうと思います。

ECS運用の次世代ツールきたか…!!

　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

メインリソース

メインのリポジトリはこちら。

aws/copilot-cli: The AWS Copilot CLI is a tool for developers to build, release and operate production ready containerized applications on Amazon ECS and AWS Fargate.

マニュアルはこちらにまとめられています。

Getting Started · aws/copilot-cli Wiki

以降、マニュアルのGetting Startedをなぞりながら、実際にAWS側にどんなリソースが出来上がっていくのか見ていこうと思います。

AWS Copilotのインストール

Installation · aws/copilot-cli Wiki

curlコマンドで、直接ダウンロードしてインストール形式です。macOSではこちら。簡単。

curl -Lo /usr/local/bin/copilot https://github.com/aws/copilot-cli/releases/download/v0.1.0/copilot-darwin-v0.1.0 && chmod +x /usr/local/bin/copilot && copilot --help

Getting Started

AWS Copilotと周辺ツールのセッティング

AWS Copilotの動作には、本体のバイナリ以外に、AWS CLIやDockerのインストールが別途必要です。また、AWS環境に接続するための認証情報も。そのあたりは、事前に済ませておきましょう。

サンプルアプリケーションのダウンロード

aws-samplesリポジトリに、aws copilotを試すためのサンプルアプリケーションがアップロードされているので、それをダウンロード。

$ git clone https://github.com/aws-samples/aws-copilot-sample-service example
$ cd example

アプリケーションのセットアップ

ECSアプリケーションのセットアップを実施していきます。

$ copilot init

対話形式で、デプロイするアプリケーションの名前を聞かれます。example-appと入力。

次にサービスのタイプを聞かれます。2つ選択肢がありますが、大きくは以下の違いです。

Load Balanced Web Service：インターネットフェーシングなパブリックサービス
Backend Service：プライベートなバックエンドサービス

今回は、Load Balanced Web Serviceを選択。

次に、Loadd Balanced Web Serviceの名前を聞かれるので、front-endと入力。

最後に、デプロイするコンテナのDockerfileについて聞かれるので、カレントディレクトリにある./Dockerfileを選択。

そうすると、以下のプロンプトが表示されます。

しばらく待つと、これら関連リソースが作成されます。カレントディレクトリには.workspaceというアプリケーション名を記載したファイルが作成されます。

application: example-app

また、サービス名でディレクトリが作成され、その中にYAML形式のマニフェストファイルが作成されます。

# The manifest for the "front-end" service.
# Read the full specification for the "Load Balanced Web Service" type at:
#  https://github.com/aws/amazon-ecs-cli-v2/wiki/Manifests#load-balanced-web-svc

# Your service name will be used in naming your resources like log groups, ECS services, etc.
name: front-end
# The "architecture" of the service you're running.
type: Load Balanced Web Service

image:
  # Path to your service's Dockerfile.
  build: ./Dockerfile
  # Port exposed through your container to route traffic to it.
  port: 80

http:
  # Requests to this path will be forwarded to your service. 
  # To match all requests you can use the "/" path. 
  path: '/'
  # You can specify a custom health check path. The default is "/"
  # healthcheck: '/'

# Number of CPU units for the task.
cpu: 256
# Amount of memory in MiB used by the task.
memory: 512
# Number of tasks that should be running in your service.
count: 1

# Optional fields for more advanced use-cases.
#
#variables:                    # Pass environment variables as key value pairs.
#  LOG_LEVEL: info
#
#secrets:                      # Pass secrets from AWS Systems Manager (SSM) Parameter Store.
#  GITHUB_TOKEN: GITHUB_TOKEN  # The key is the name of the environment variable, the value is the name of the SSM parameter.

# You can override any of the values defined above by environment.
#environments:
#  test:
#    count: 2               # Number of tasks to run for the "test" environment.

暫く待つと、これらをtest環境にアップしてよいかどうか聞かれるので、yで作成。

あとは、AWS環境に環境一式がデプロイされるのを10分弱待ちます。

最終的に処理が完了し、作成されたロードバランサーのエンドポイントが表示されるので、そこにアクセスし、無事アプリケーションの内容が表示されればGetting StartedはOKです。

実際に作成されたAWSリソース

このあたりまで全自動でめちゃくちゃ楽なんですが、ここまでのGetting Startedで作成されたAWSリソースが実際どれだけあるか紹介します。

リソースの一覧ですが、CloudFormationを眺めるのが早い。実際にCopilotから生成されたAWSリソースは全てCloudFormationベースで管理されているようです。

スタック名で作成順に並べていくと以下の通りです。

hamada-app-infrastructure-roles
- AWS::IAM::Role
hamada-app-test
- AWS::EC2::VPC
- AWS::ServiceDiscovery::PrivateDnsNamespace
- AWS::EC2::SubnetRouteTableAssociation
- AWS::EC2::Subnet
- AWS::EC2::SubnetRouteTableAssociation
- AWS::EC2::Subnet
- AWS::EC2::RouteTable
- AWS::EC2::SecurityGroup
- AWS::ElasticLoadBalancingV2::LoadBalancer
- AWS::EC2::VPCGatewayAttachment
- AWS::EC2::InternetGateway
- AWS::ElasticLoadBalancingV2::Listener
- AWS::Lambda::Function
- Custom::EnableLongARNFormatFunction
- AWS::ECS::Cluster
hamada-app-StackSet〜
- AWS::S3::BucketPolicy
- AWS::S3::Bucket
- AWS::KMS::Key
- AWS::ECR::Repository
hamada-app-test-front-end
- AWS::CloudFormation::WaitCondition
- AWS::IAM::Role
- AWS::ECS::TaskDefinition
- AWS::ElasticLoadBalancingV2::TargetGroup
- AWS::ECS::Service
- AWS::Lambda::Function
- AWS::ServiceDiscovery::Service

ざっと眺めた限りでは、VPCに関連する足回りのリソース全てと、ECS関連のリソースが一通り作成されていることがわかります。パブリックなアプリケーションでLoadBalancerを指定したからか、プライベートサブネットは存在するものの、NAT Gatewayはありません。

Copilotの他のコマンドを動かしてみる

Getting Startedの内容はここまでですが、もうちょっと他のコマンドを実行してみます。Copilotには大きく3つのリソースがあるんですが、それらの関係性をざっくり把握するのが、Copilot理解の近道です。ECSリソースとの関連を記載するとこうなります。

Environment
Application
Service

Environment（環境）

環境は、アプリケーションデプロイのステージを表します。具体的には、開発環境、ステージング環境、本番環境などの差分を表し、それぞれの環境はリソースとして独立して存在します。Getting Started直後、作成されている環境はtestのみ。

$ copilot env ls
test

新しい環境も簡単にワン・コマンドでセットアップできます。

$ copilot env init
Which named profile should we use to create stg? default
⠼ Creating the infrastructure for the stg environment. 
- Virtual private cloud on 2 availability zones to hold your services     [Complete]
  - Internet gateway to connect the network to the internet               [In Progress]
  - Public subnets for internet facing services                           [In Progress]
  - Private subnets for services that can't be reached from the internet  [In Progress]
  - Routing tables for services to talk with each other                   [In Progress]
- ECS Cluster to hold your services                                       [Complete]
- Application load balancer to distribute traffic                         [In Progress]

Application（アプリケーション）

Copilotにおいて、アプリケーションは、システムの構成要素をグルーピングした全体のことを指します。言ってしまえば、開発〜運用の単位といえます。app lsで、アプリケーションの一覧を。app showで、アプリケーションに含まれるサービスや環境の一覧を表示できます。

$ copilot app ls
hamada-app
$ copilot app show
About

  Name              hamada-app
  URI               

Environments

  Name              AccountID           Region
  test              123456789012        ap-northeast-1

Services

  Name              Type
  hamada-front-end  Load Balanced Web Service

Service（サービス）

サービスは、コンテナを実行する常駐型サービスのことを指します。具体的にはECSのサービスをイメージするとわかりやすいかと。Getting Started直後は、一つのサービスが登録されている状態です。

$ copilot svc ls
Name                Type
----------------    -------------------------
hamada-front-end    Load Balanced Web Service

サービスで出力されるログの確認。

$ copilot svc logs hamada-front-end
Showing logs of service hamada-front-end deployed in environment test
hamada-front-end/b8330a7f 10.0.1.23 - - [09/Jul/2020:23:00:44 +0000] "GET / HTTP/1.1" 200 22379 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.0.95 - - [09/Jul/2020:23:00:47 +0000] "GET / HTTP/1.1" 200 22374 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.1.23 - - [09/Jul/2020:23:00:54 +0000] "GET / HTTP/1.1" 200 22380 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.0.95 - - [09/Jul/2020:23:00:57 +0000] "GET / HTTP/1.1" 200 22369 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.1.23 - - [09/Jul/2020:23:01:04 +0000] "GET / HTTP/1.1" 200 22379 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.0.95 - - [09/Jul/2020:23:01:07 +0000] "GET / HTTP/1.1" 200 22371 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.1.23 - - [09/Jul/2020:23:01:14 +0000] "GET / HTTP/1.1" 200 22379 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.0.95 - - [09/Jul/2020:23:01:17 +0000] "GET / HTTP/1.1" 200 22373 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.1.23 - - [09/Jul/2020:23:01:24 +0000] "GET / HTTP/1.1" 200 22377 "-" "ELB-HealthChecker/2.0"
hamada-front-end/b8330a7f 10.0.0.95 - - [09/Jul/2020:23:01:27 +0000] "GET / HTTP/1.1" 200 22374 "-" "ELB-HealthChecker/2.0"

サービスのステータスの確認

$ copilot svc status hamada-front-end
Showing status of service hamada-front-end deployed in environment test
Service Status

  ACTIVE 1 / 1 running tasks (0 pending)

Last Deployment

  Updated At        38 minutes ago
  Task Definition   arn:aws:ecs:ap-northeast-1:629895769338:task-definition/hamada-app-test-hamada-front-end:1

Task Status

  ID                Image Digest        Last Status         Health Status       Started At          Stopped At
  b8330a7f          16d9491f            RUNNING             UNKNOWN             38 minutes ago      -

Alarms

  Name              Health              Last Updated        Reason

既存のサービスからCloudFormationテンプレートを出力するpackageコマンドもあります。

$ copilot svc package
Only found one service, defaulting to: hamada-front-end
Which environment would you like to package this stack for? test
↓以下、CloudFormationテンプレート

環境のお掃除

アプリケーションコマンドにdeleteコマンドがあり、それを利用することで、環境一式まるまる削除が可能です。

$ copilot app ls
hamada-app
$ copilot app delete hamada-app
Are you sure you want to delete application hamada-app? Yes
⠧ Deleting service hamada-front-end from environment test.

ECS周辺の運用に必要なコマンドを高レイヤーでまとめた高機能ツール

ECS周辺のツールは、OSSなものも含めて非常に沢山あります。Fargateへのデプロイのためだけのツールでも5個以上あったかと思いますが、Copilotをちょっと触ってみた感じでは、「非常に高レイヤーでECSの開発〜運用に関わるライフサイクル全般をまるっとまとめて提供するツール」という印象です。

最初さわるまでは、正直ここまで高レイヤーのツールとは思ってませんでした。特に、今回は試せていないですが、デプロイパイプラインの構築もこのツールの中に含まれているのは、そこまでやるんか！って思いましたね。高レイヤーのツールになればなるほど、細かいカスタマイズがしづらかったり、そもそもできなかったりというのがよくありますが、Copilotではどこまで対応しているのか、今後もう少し掘り下げてみようと思ってます。